Mr-Ojii版L-SMASH Works r1087以降 出力処理が重い
対処法
InputPipePlugin v1.8以前を導入している場合、InputPipePlugin v1.9以降に更新してください (これによりv2.0以降に更新する場合は、lwinput64.auiもきちんと導入すること)
上記の対処法で解決しなかった場合、別の原因が考えられますので、GitHubのIssuesなどで教えていただけると助かります。
考えられる原因
r1087以降、lsmash.iniの読み込みをfunc_init関数で行うようにしました。(メモリリーク修正のため)
InputPipePlugin v1.8以前を導入している場合、L-SMASH Worksのfunc_init関数が呼ばれないため、内部の設定がすべて0(文字列に関しては、何も書いていない状態)になってしまいます。
よって、Forward thresholdの設定も0となります。
L-SMASH Works(r1087)のREADME.jaより、Forward thresholdの説明を引用します。
+ Forward threshold : アップダウンコントロール (デフォルト値 : 10)
最近傍RAPから復号を始めて要求された映像フレームを取得するかどうかの閾値です。
* RAPとはランダムアクセス可能ポイントのことです。
ここで
- Tをその閾値、
そして
- N番目のフレームf(N)からM番目のフレームf(M)にシークを要求したとしましょう。
もし、M > N 且つ M - N <= T ならば
デコーダはf(M)を取得するために、f(N)から連続的にフレームを復号することを試みます。
もし、M < N または M - N > T ならば
先ず、最近傍RAPを確認します。
確認の後、もし最近傍RAPが最後にアクセスしたRAPと同一であるならば、M > N 且つ M - N <= T のケースと同じ処理を行います。
それ以外の場合、f(M)を取得するために、その最近傍RAPから連続的にフレームを復号することを試みます。
上記の説明にT=0を当てはめてみると、別フレームにシークを要求した際、
M < N または M - N > T
に必ず当てはまってしまいます。
よって、別のフレームの復号をする際には、必ず「最近傍RAPを確認する」という無駄となり得る処理が挟まれてしまうため、重くなると考えられます。
(理解しやすくするため、説明について少し省いている箇所が存在します。)
内部の設定が0になってしまうことを実際に確認したいのであれば、
・InputPipePlugin v1.8以前
・Mr-Ojii版L-SMASH Works r1087以降
を導入した環境を用意し、VFR->CFRを有効化した状態で動画を読み込ませてください。
VFR->CFRを有効化したにもかかわらず、機能が動作しないはずです。
(これは、VFR->CFRを有効化する設定が0(false)になり、無効化されてしまうことにより発生します)
追記
語気が強くなってしまって、非常に申し訳ない
迅速な対応をしてくださったamate氏に感謝申し上げます
#L-SMASH_Works
#AviUtl